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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document gives the stage 2 description of the call transfer supplementary services. 

Only one call transfer supplementary service has been defined, this is the Explicit Call Transfer (ECT) supplementary 
service, and is described in the present document. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "3G Vocabulary". 

[2] 3GPP TS 23.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 2". 

[3] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols - Stage 

3". 

[4] EN 300 368: "Integrated Services Digital network (ISDN); Explicit Call Transfer (ECT) 

supplementary service; Functional capabilities and information flows". 

[5] EN 300 356-14: "Integrated Services Digital network (ISDN); SignalHng System No. 7; ISDN 

User Part (ISUP) version 3 for the international interface; Part 14: Explicit Call Transfer (ECT) 
supplementary service " . 

[6] 3GPP TS 23.01 1 : Technical realization of Supplementary Services'. 

[7] 3GPP TS 23.018: 'Basic Call Handling'. 

3 Definitions and abbreviations 
3.1 Definitions 

First call: One of the subscriber A calls (answered). 

Notification Indicator (NI): Indicates to each remote party in which state of the other remote party ECT was 
performed (active, alerting). 

Redirection Number (Rdn): Includes the presentation indicator and the directory number of the other remote party. 

Second call: The other subscriber A call (answered or alerting). 

Subscriber A (PARTY A): The served mobile subscriber - the one who has subscribed to, and invokes the ECT 
Supplementary Service. 

Subscriber B (PARTY B): The other party in the subscriber A first call. 

Subscriber C (PARTY C): The other party in the subscriber A second call. 

Subscriber D (PARTY D): The forwarded-to party when the call is forwarded by the subscriber C. 
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Transferred call: The resulting call after successful explicit call transfer between B and C. 

3.2 Abbreviations 

In addition to those below, abbreviations used in the present document are listed in 3GPP TR 21.905 [1]. 

ECT: Explicit Call Transfer supplementary service 

LI: Line Identity 

NI: Notification Indicator 

Rdn: Redirection number 

RdnB: Redirection number of party B 

RdnD: Redirection number of party D 



Explicit Call Transfer (ECT) 



4.1 Functions 

The following function has been identified for the explicit call transfer service: 

MAF027 

Explicit Call Transfer related authorizations examination 

The ability of a PLMN component to determine the authorizations relating to explicit call transfer. See figure 
1. 

Location: VLR 
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Process MAF027 

Process in the VLB to check 
if ECTIs ptDvisioned. 



indicator:= 
ECTavailabie 



Idie 



Check ECT 
subscriptior 




No 



Yes 



ss-csr 

provisioned 




Yes 




Yes 



lndicator:= 

ECTavailabie 

+ SS-CSI 



Process 
ECT 



Idie 



indicator:= 
ECT_not_ 
availabie 



39i_i(i: 



Signals to/from the ieft are[ 
to/from the MSC. 



Figure 1 : Explicit Call Transfer related authorizations examination (VLR) 
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4.2 SDL diagrams and information flows 
4.2.1 General description 

The procedures Handle_ECT_Active and Handle_ECT_Alerting show the behaviour of the service as perceived by the 
served mobile subscriber and by any of the other parties involved in the transfer. These procedures and the macro 
Check_ECT show the actions to be taken by the network and the information provided by the network to the users. 

The following states for the invocation of the ECT supplementary service are defined: 

a) First Call (Active, Held), Second Call (Active, Idle); 

b) First Call (Active, Held), Second Call (Call Delivered, Idle). 

NOTE: The call state "call delivered" means that an ALERTING message has been sent to the MS, but no 
ANSWER Message (ANM) has been received. 

In the information flows it is assumed that the served subscriber is a mobile subscriber and that the other parties are 
mobile or fixed subscribers. 

Party A is the subscriber controlling the Explicit Call Transfer Call (served mobile subscriber). Party B is the first 
remote party called. Party C is the second remote party called. 

The served party is disconnected by the generic disconnect/release procedure after a successful transfer request. The 
connection of the remote parties in a new call (transferred call) is located in the served subscriber"s MSC. 

The information flows in figures 4 and 7 show the unsuccessful case (i.e. the check in the VLR or in the MSC fails). 

The information flows in figures 5 and 8 show the successful case. 



4.2.2 ECT (both calls answered) 



The SDL for the procedure Handle_ECT_Active (Explicit Call Transfer - both calls have been answered) is shown in 
figure 2. 

The checks of whether Explicit Call Transfer is barred or not are shown in figure 3. 

The corresponding information flows are given in figure 4 and figure 5. 
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Procedure Handle_ECT_Active 

I ]■ 

Procedure in the originating IVISC to handle i ^ 
an Explicit Call Transfer when the first call leg^ 
(A-B) is connected and on hold and the other 
call leg (A-C) is connected and active. 



For call legs 
A-B & A-C 



Pass 



Connect both 
calls 



To the held party i 



Retrieve 
notification 



Transfer 
notification 



ECTack 




No 



Disconnect 
request 



Result:=Pass 




ECT_Ac(1) 



Signals to/from the left are ^ 
to/from the MS; 
signals to/from the right are 
to/from all/any remote parties 
unless stated otherwise. 



Check_ECT 



Fail 



ECT 
reject 



Result:=Fail 




Yes 



SS InvocatiotK 
notify / 



^TogsmSCF 



Figure 2: Procedure Handle_ECT_Active 
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Macrodefinition Check_ECT 

I h 

Macro in the originating IVISC to check if [ i^ 
an Explicit Call Transfer can be performedi 



i(i: 



ECTTreatment Indicator 
present in SII2 (for 
either ongoing call)'? 



Yes 




No 



ECTTreatment Indicator 
set to Rejed ECT request 
(for either ongoing call)? 



Check ECT ^ 
subscription/ 



/ Wait_For_ \ 
|ECT_Status_! 
\ — Reply — / 




Figure 3: Macro CheckECT 
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MSa MSCa VLRa 

A-B (active, held) / A-C (active, idle) 



MSb 



ECT request 



ECT rej 



I 

I info request 

I > 



I info ack 

I < 



0R1:N 
I 
I 
I 



I 



TEca 

I 1 



A-B (active, held) / A-C (active, idle) 
I II II 

NOTE: ORl : Checks in VLR and MSC ok? (Y: yes N: no). 

Figure 4: Information flow for failed explicit call transfer request (both calls answered) 



MSa MSCa VLRa 

A-B (active, held) / A-C (active, idle) 



TEc 
I "I 



I I 

ECT request | | 
> I I info request 

I I > 

I I 

I I info ack 

I I < 

|0R1:Y 

I I 



I 
I 

MAF027 

I 
I 
I 
I 
I 
I 



connect calls 

I I 

I I notification (retrieve) 

I I , 

II II 

I I notification (ECT) 

I I , 

I I (active, Rdn) 

II II 
II II 

I I notification (ECT) 

I I 

I I (active, Rdn) 

I I 

ECT ack I I 

< I I 

disc req A-B | | 

< I I 

NORMAL DISCONNECTION A-B 

I I 
disc req A-C | | 

< I I 

NORMAL DISCONNECTION A-C 

I I 
B-C (active, idle) | 
I 



I 
I 
notification (retr) 

> I 

I 

notification (ECT) 

> I 

(active , Rdn) | 

I 



notification (ECT 



(active , Rdn) 



I I I 

NOTE: ORl : Checks in VLR and MSC ok? (Y: yes N: no). 

Figure 5: Information flow for successful explicit call transfer (both calls answered) 



4.2.3 ECT (one call answered, the other alerting) 

The SDL for the procedure Handle_ECT_Alerting (Explicit Call Transfer - one call answered, the other alerting) is 
shown in figure 6. 

The checks of whether Explicit Call Transfer is barred or not are shown in figure 3. 
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The corresponding information flows are given in figure 7 and figure 8. 



Procedure Handle_ECT_Alerting 

Procedure in the originating IVISC to handle i 
an Explicit Call Transfer when the first call leg^ 
(A-B) is connected and on hold and the other 
call leg (A-C) is connected and alerting. 



ECT_AI(1 ; 



Result:=Pass 





Signals to/from the left are Q^ 
to/from the MS; 
signals to/from the right are 
to/from all/any remote parties 
unless stated otherwise. 



For call legs 
I A-B & A-C 



Figure 6: Procedure Handle_ECT_Alerting 
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MSa MSCa VLRa MSCb 

A-B (active, held) / A-C (call delivered, idle) | 



MSb 



TEc 
I "I 



I 

ECT request | | 



I info request | | 



I > 

I 

I info ack 



ECT rej 



|0R1:N 
I 
I 
I 



I 
IMAF027 

I 
I 
I 
I 
I 
I 



A-B (active, held) / A-C (call delivered, idle) 
I II II 

NOTE: ORl : Checks in VLR and MSC ok? (Y: yes N: no). 



Figure 7: Information flow for failed explicit call transfer request 
(one call answered, the other alerting) 
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MSa MSCa VLRa MSCb 

A-B (active, held) / A-C (call delivered, idle) | 



MSb 



ECT request 



disc req A- 



disc req A-C 



A idle, B hears C 



I I I 

I I I 

I info request | | 

I > I I 

I |MAF027 

I info ack | | 

I < I I 

|0R1:Y I I 

I I I 

connect calls | | 

I I I 

I notification (retrieve) 

I 

I I I 

I notification (ECT) 
I 

I (alerting) 

I I I 

I notification (ECT) 



ringing 



(active, Rdn) 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

;wER I I 



-C active , idle 



I I 

I I 

notification (ECT) 

(active, Rdn) 

I I 

I I 

I I 

I I 

I I 



I 
I 

notification (retr) 

> I 

I 

notification (ECT) 

> I 

(alerting) | 

I 



I 



notification (ECT) 

> I 

(active , Rdn) | 

I 



TEc 
I "I 



notification (ECT 



(active, Rdn) 



CONNECT ACK 



I I I 

NOTE: ORl : Checks in VLR and MSC ok? (Y: yes N: no). 



Figure 8: Information flow for successful explicit call transfer 
(one call answered, the other alerting) 



4.3 Interaction with other supplementary services 
4.3.1 Line Icdentification services 

Tables 1 to 4 indicate the information to be provided in the Notification Indicator (NI) and the Redirection Number 
(Rdn) when the subscribers B and C are notified. Call states refer to the situation before ECT invocation. At that time 
one of the calls is on hold. 

If user B was the called subscriber in the call A-B, table 1 applies to the information supplied to subscriber C. If user B 
was the calling subscriber in the call A-B, table 2 applies to the information supplied to subscriber C. 

Mobile subscriber A has an active call to subscriber B and: 

- puts the active call on hold and calls subscriber C, table 3 applies to the information supplied to subscriber B; 

- receives and accepts a call from subscriber C (by putting B on Hold), table 4 applies to the information supplied 
to subscriber B. 
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Table 1 : Mobile subscriber A was calling subscriber B, puts B on hold and calls subscriber C 



Call states 


COLR indication received from 
subscribers B's network 


Information provided to C 


A-B Active 

A-C Active / Alerting 


Indicated "allowed" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = allowed, LI of B 


A-B Active 

A-C Active / Alerting 


Indicated "restricted" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = restricted (note 1) 


A-B Active 

A-C Active / Alerting 


No indication received 
(e.g. interworking) 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = not available 



Table 2: IVIobile subscriber A was called by subscriber B, puts B on hold and calls subscriber C 



Call states 


CLIR indication received from 
subscribers B's network 


Information provided to C 


A-B Active 


Indicated "allowed" 


At time of transfer: 


A-C Active / Alerting 




Nl: "call transferred, active" 
Rdn: PI = allowed, LI of B 


A-B Active 


Indicated "restricted" 


At time of transfer: 


A-C Active / Alerting 




Nl: "call transferred, active" 
Rdn: PI = restricted (note 1) 


A-B Active 


No indication received 


At time of transfer: 


A-C Active / Alerting 


(e.g. interworking) 


Nl: "call transferred, active" 
Rdn: PI = not available 



NOTE 1 : If the subscriber C has CLIP Override Category then the following information is carried in the 
Redirection number: PI = restricted, LI of B. 
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Table 3: Mobile subscriber A puts the call to B on hold and calls subscriber C 



Call states 


COLR indication received from 
subscribers C's network 


Information provided to B 


A-B Active 


Indicated "allowed" 


At time of transfer: 


A-C Active 




Nl: "call transferred, active" 
Rdn: PI = allowed, LI of C 


A-B Active 


Indicated "restricted" 


At time of transfer: 


A-C Active' 




Nl: "call transferred, active" 
Rdn: PI = restricted (note 2) 


A-B Active 


No indication received 


At time of transfer: 


A-C Active 


(e.g. interworking) 


Nl: "call transferred, active" 
Rdn: PI = not available 


A-B Active 


Indicated "allowed" at receipt of 


At time of transfer: 


A-C Alerting 


CONNECT by subscriber C 


Nl: "call transferred, alerting" 
At subscribers C CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = allowed, LI of C 


A-B Active 


Indicated "restricted" at receipt of 


At time of transfer: 


A-C Alerting 


CONNECT by subscriber C 


Nl: "call transferred, alerting" 
At subscribers C CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = restricted (note 2) 


A-B Active 


No indication received at receipt of 


At time of transfer: 


A-C Alerting 


CONNECT by subscriber C 


Nl: "call transferred, alerting" 




(e.g. interworking) 


At subscribers C CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = not available 



Table 4: IVIobile subscriber A was called by subscriber C and accepts the call by putting subscriber B 

on hold 



Call states 


CLIR indication received from 
subscriber C's network 


Information provided to B 


A-B Active 
A-C Active 


Indicated "allowed" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = allowed, LI of C 


A-B Active 
A-C Active 


Indicated "restricted" 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = restricted (note 2) 


A-B Active 
A-C Active 


No indication received 
(e.g. interworking) 


At time of transfer: 

Nl: "call transferred, active" 

Rdn: PI = not available 



NOTE 2: If the subscriber B was called by subscriber A and has CLIP Override Category, or if subscriber B called 
subscriber A and has COLP Override Category then the following information is carried in the 
Redirection number: PI = restricted, LI of C 

4.3.2 Call Forwarding Unconditional (CFU) 

No impact. 
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4.3.3 Call Forwarding on mobile subscriber Busy (CFB) 



4.3.3.1 



No impact. 



4.3.3.2 



Call Forwarding on mobile subscriber Busy due to Network Determined User 
Busy (NDUB) 



Call Forwarding on mobile subscriber Busy due to User Determined User 
Busy (UDUB) 



When subscriber A transfers the forwarded call there is no impact. 

When subscriber C forwards the transferred call to the forwarded-to subscriber D due to UDUB the line identity 
information of the subscriber B that was received by the subscriber C in the ECT invocation notification shall be sent as 
calling line identity to the forwarded-to subscriber D instead of the line identity of the subscriber A. The corresponding 
information flow is given in figure 9. For the line identity information sent to the subscriber B after the call is answered 
by the forwarded-to subscriber D the table 5 applies. 



I — 1 I — 1 I — 1 I — 1 

A-B (active, held) / A-C (call delivered, idle) 



MSb 
I 1 



ECT request 



|0R1:Y 
connect calls 

notification (retrieve) 



disc req A-B 



disc req A-C 



info request 



info ack 



I 

I 

MAF02 7 

I 
I 
I 
I 
I 
I 



I I 

notification (ECT) 
(alerting) 

I I 

notification (ECT) 



(active, RdnB) 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 



I I 

notification (ECT) 
(active, RdnD) 

I I 
I I 



notification 
> 

(retrieve) 

notification (ECT) 



(alerting) 



ANSWER (LI-D) 



notification (ECT) 



(active , RdnD) 



notification (ECT) 

> I 

(active, RdnB) | 

I 
reject (UDUB) | 
= 1 



I 

set up (LI=RdnB 




MSCd MSd 

n I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

I I 

setup 

l->l 

I I 

connect 

I I 

con ack 

I I 

I I 

I I 

I I 



NOTE: ORl : Checks in VLR and MSC ok? (Y: yes N: no) 

Figure 9: Information flow for interaction of explicit call transfer (one call answered, the other alerting) with call 

forwarding 
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Table 5: Subscriber C forwards the transferred call to the subscriber D 



Call states 


COLR indication received from 
subscribers D's network 


Information provided to B 


A-B Active 


Indicated "allowed" at receipt of 


At time of transfer: 


A-C Alerting, 


CONNECT by subscriber D 


Ml: "call transferred, alerting" 


forwarded to D 




At subscribers D CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = allowed, LI of D 


A-B Active 


Indicated "restricted" at receipt of 


At time of transfer: 


A-C Alerting, 


CONNECT by subscriber D 


Nl: "call transferred, alerting" 


forwarded to D 




At subscribers D CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = restricted (note 1) 


A-B Active 


No indication received at receipt of 


At time of transfer: 


A-C Alerting, 


CONNECT by subscriber D 


Nl: "call transferred, alerting" 


forwarded to D 


(e.g. interworking) 


At subscribers D CONNECT: 
Nl: "call transferred, active" 
Rdn: PI = not available 



NOTE 1 : If the subscriber B was called by subscriber A and has CLIP Override Category, or if subscriber B called 
subscriber A and has COLF Override Category then the following information is carried in the 
Redirection number: PI = restricted, LI of D. 

4.3.4 Call Forwarding on No Reply (CFNRy) 

Same as the interaction between call forwarding on mobile subscriber busy due to UDUB and explicit call transfer as 
described in subclause 4.3.3.2. 

Figure 9 applies except that call forwarding is invoked by the CFNRy timer expiry instead of reception of reject 
(UDUB) message. 

For the line identity information sent to the subscriber B after the call is answered by the forwarded-to subscriber D the 
table 5 applies. 

4.3.5 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 

No impact. 

4.3.6 Call Waiting (CW) 

No impact. 

4.3.7 Call Hold (HOLD) 

No impact. 

4.3.8 Multi Party (MPTY) 

The MSC/VLR shall reject any ECT request from the served subscriber of a MPTY call. 

4.3.9 Closed User Group (CUG) 

Closed user group restrictions shall be met between users when the first call is set up. 

Similarly, closed user group restrictions shall also be met between users when setting up the second call. 

Finally, for successful explicit call transfer the served mobile subscriber must use the same CUG-Interlock code for 
both calls. The same rule shall applied regardless of being two MO calls, two MT calls or one MO and one MT call. 
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4.3.1 Advice of Charge (AoC) services 

No impact. 

4.3.1 1 Call Barring services 

No impact 

4.3.12 Explicit Call Transfer (ECT) 

It is required as a network option that the establishment of endless loops between subscriber A and subscriber B, both of 
them transferring the call to the other one, is prevented. The same loop prevention mechanism as in ISDN shall be used. 



4.4 



Information stored in the HLR 



The following logical states are applicable for the Explicit Call Transfer service (refer to 3GPP TS 23.01 1 [6] for an 
explanation of the notation): 



Provisioning State 

(Not Provisioned, 
(Provisioned, 



Registration State 

Not Applicable, 
Not Applicable, 



Activation State 

Not Active, 

Active and Operative, 



HLR Induction State 

Not Induced) 
Not Induced) 



The HLR shall store the logical state of the Explicit Call Transfer service (which shall be one of the valid states listed 
above) on a per subscriber basis. 



4.5 



State transition model 



Figure 10 shows the successful cases of transition between the applicable logical states of the Explicit Call Transfer 
service. The state changes are caused by actions of the service provider. 

Note that error cases are not shown in the diagram as they normally do not cause a state change. Additionally, some 
successful requests may not cause a state change and are therefore not shown in the diagram. 

Provision 



(Not Provisioned, 

Not Applicable, 

Not Active, 

Not Induced) 




(Provisioned, 

Not Applicable, 

Active and Operative, 

Not Induced) 



Withdrawal 
Figure 10: State transition model 
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4.6 Transfer of information from the HLR to the VLR 

If the provisioning state for the ExpHcit Call Transfer service is "Provisioned" then when the subscriber registers on a 
VLR the HLR shall send that VLR information about the logical state of the Explicit Call Transfer service. 

If the logical state of the Explicit Call Transfer service is changed while a subscriber is registered on a VLR then the 
HLR shall inform the VLR of the new logical state of the Explicit Call Transfer service. 

4.7 Information stored in the VLR 

For the supplementary service Explicit Call Transfer the VLR shall store the service state information received from the 
HLR. 

4.8 Handover 

Handover will have no impact on the control procedures and the operation of the service. 
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